home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d12 / stevie.arc / SOURCE.DOC < prev    next >
Text File  |  1990-01-10  |  5KB  |  134 lines
  1.  
  2.          Release Notes for STEVIE - Version 3.10
  3.  
  4.                   Source Notes
  5.  
  6.                   Tony Andrews
  7.  
  8.                   3/6/88
  9.  
  10.  
  11. Overview
  12. --------
  13.  
  14.     This file provides a brief description of the source code for
  15. Stevie. The data structures are described later as well. For information
  16. specific to porting the editor, see the file 'porting.doc'. This document
  17. is more relevant to people who want to hack on the editor apart from doing
  18. a simple port.
  19.  
  20.     Most of this document was written some time ago so a lot of the
  21. discussion centers on problems related to the Atari ST environment and
  22. compilers. Most of this can be ignored for other systems.
  23.  
  24. Things You Need
  25. ---------------
  26.  
  27.     Stevie has been compiled with both the Alcyon (4.14A) and the
  28. Megamax C compilers. For the posted binary, Megamax was used because
  29. it's less buggy and provides a reasonable malloc(). Ports to other
  30. compilers should be pretty simple. The current ifdef's for ALCYON and
  31. MEGAMAX should point to the potential trouble areas. (See 'porting.doc'
  32. for more information.)
  33.  
  34.     The search code depends on Henry Spencer's regular expression
  35. code. I used a version I got from the net recently (as part of a 'grep'
  36. posting) and had absolutely no trouble compiling it on the ST. Thanks,
  37. Henry!
  38.  
  39.     The file 'getenv.c' contains a getenv routine that may or may
  40. not be needed with your compiler. My version works with Alcyon and
  41. Megamax, under either the Beckemeyer or Gulam shells.
  42.  
  43.     Lastly, you need a decent malloc. Lots of stuff in stevie is
  44. allocated dynamically. The malloc with Alcyon is problematic because
  45. it allocates from the heap between the end of data and the top of stack.
  46. If you make the stack big enough to edit large files, you wind up
  47. wasting space when working with small files. Mallocs that get their memory
  48. from GEMDOS (in fairly large chunks) are much better.
  49.  
  50.  
  51. Cruft
  52. -----
  53.  
  54.     Some artifacts from Tim Thompson's original version remain. In
  55. some cases, code has been re-written, with the original left in place
  56. but ifdef'd out. This will all be cleaned up eventually, but for now
  57. it's sometimes useful to see how things used to work.
  58.  
  59.  
  60. Data Structures
  61. ---------------
  62.  
  63.     A brief discussion of the evolution of the data structures will
  64. do much to clarify the code, and explain some of the strangeness you may
  65. see.
  66.  
  67.     In the original version, the file was maintained in memory as a
  68. simple contiguous buffer. References to positions in the file were simply
  69. character pointers. Due to the obvious performance problems inherent in
  70. this approach, I made the following changes.
  71.  
  72.     The file is now represented by a doubly linked list of 'line'
  73. structures defined as follows:
  74.  
  75. struct    line {
  76.     struct    line    *prev, *next;    /* previous and next lines */
  77.     char    *s;            /* text for this line */
  78.     int    size;            /* actual size of space at 's' */
  79.     unsigned int    num;        /* line "number" */
  80. };
  81.  
  82. The members of the line structure are described more completely here:
  83.  
  84. prev    - pointer to the structure for the prior line, or NULL for the
  85.       first line of the file
  86.  
  87. next    - like 'prev' but points to the next line
  88.  
  89. s    - points to the contents of the line (null terminated)
  90.  
  91. size    - contains the size of the chunk of space pointed to by s. This
  92.       is used so we know when we can add text to a line without getting
  93.       more space. When we DO need more space, we always get a little
  94.       extra so we don't make so many calls to malloc.
  95.  
  96. num    - This is a pseudo line number that makes it easy to compare
  97.       positions within the file. Otherwise, we'd have to traverse
  98.       all the links to tell which line came first.
  99.  
  100.  
  101.     Since character pointers served to mark file positions in the
  102. original, a similar data object was needed for the new data structures.
  103. This purpose is served by the 'lptr' structure which is defined as:
  104.  
  105. struct    lptr {
  106.     struct    line    *linep;        /* line we're referencing */
  107.     int    index;            /* position within that line */
  108. };
  109.  
  110.  
  111. The member 'linep' points to the 'line' structure for the line containing
  112. the location of interest. The integer 'index' is the offset into the line
  113. data (member 's') of the character to be referenced.
  114.  
  115. The following typedef's are more commonly used:
  116.  
  117. typedef    struct line    LINE;
  118. typedef    struct lptr    LPTR;
  119.  
  120. Many operations that were trivial with character pointers had to be
  121. implemented by functions to manipulate LPTR's. Most of these are in the
  122. file 'ptrfunc.c'. There you'll find functions to increment, decrement,
  123. and compare LPTR's.
  124.  
  125. This was the biggest change to the editor. Fortunately, I made this
  126. change very early on, while I was still doing the work on a UNIX system.
  127. Using 'sdb' made it much easier to debug this code than if I had done it
  128. on the ST.
  129.  
  130.  
  131. Summary
  132. -------
  133.  
  134.